I'm personally pretty nervous about the direction this abstraction is headed in. As is it seems like it's incredibly difficult to get right in terms of preventing race conditions and other undefined behavior, and it's barely leveraging Rust types for managing this unsafety. Specifically this structure is conglomeration of:

• Raw unsafe pointers
• non-thread-safe Cell types
• threadsafe atomics

This, combined with the fn inner_mut(&self) -> &mut ReadinessQueueInner signature below, make this very difficult to determine whether it's actually safe or not.

I think this would benefit quite a bit from extracting some of the unsafe components here to standalone and isolated features with safe interfaces, or very very clear unsafe interfaces with documentation as to what contracts need to be upheld. For example next_all_notes and prev_all_nodes looks a lot like a doubly linked list? Does the standard library's LinkedList not suffice here because atomics are necessary? Some other reason?

Similarly if there's a set of fields that are only accessed by a Poll on each node, then this may benefit from a more concrete interface to indicate such. For example I would expect something like:

struct PollFields { ... }

struct ReadinessNode {
    poll_fields: UnsafeCell<PollFields>,
}

impl ReadinessNode {
    fn poll_fields<'a>(&'a self, _proof: &'a Poll) -> &'a PollFields { /* ... */ }
}

Basically something like that where the API itself is very difficult to get wrong if properly used. That should help anyone else working around here or perhaps any future refactorings as well.

This TODO is handled, right?

Shouldn't this be using try_send?